As the number of users viewing information and purchasing items electronically increases, there is also an increasing amount of forgery, misuse of identity information, and other illicit activities in various electronic environments. Forced unauthorized commands or submissions from a trusted user of a Web site, for example, is often referred to as Cross Site Request Forgery (CSRF or XSRF). Typically, the submission is made to originate at the Internet protocol (IP) address of the user, such that the actual initiator of the submission is untraceable. The attacks often affect Web sites that use mechanisms such as state management, Web cookies, browser authentication, or client-side certificates to authenticate users. A CSRF exploit can, for example, be executed by tricking or otherwise causing a user to submit malicious data to a trusted Web site. The exploit typically originates at a malicious site, as a malicious payload in a file such as a hypertext markup language (HTML) or JavaScript file, which can contain script code triggering an action to be performed on a third-party site on behalf of the victim.
In an example where a user does banking electronically, a source such as an unauthorized third party could send a script to a user or client device that causes the user to submit a request to transfer money without the user's knowledge. Thus, a legitimate or authorized user can unknowingly submit a request to perform the transfer or another such operation as a result of the third party script.
In another example of a fraudulent submission, a user might login to an electronic marketplace that offers items for consumption, such as for purchase, rental, or download. An unauthorized script could cause a request to be submitted on behalf of the authorized user to purchase items, provide ratings, or perform any of a number of other such actions.
One conventional approach to mitigate CSRF attacks is to use the referrer header of a client request to determine whether the request is from the expected sender. While simple in complexity, the client application controls this aspect such that the referred header can be subject to spoofing by exploiting the application. In addition, some clients may omit the referrer header entirely in some circumstances. Therefore, this approach can't be relied upon with a great deal of confidence.
Another conventional approach to attempt to prevent processing of an unauthorized submission by a person or process posing as a trusted user is to generate a random number and digitally sign that number with a cryptographic key. The encrypted number is then sent to the user, for example, with the encrypted number being returned with each submission in order to verify that the request is coming from an authenticated user browsing the site. Such an approach comes with a significant amount of cryptographic processing overhead that is burdensome for many providers of electronic content, especially those of large scale and transaction volume.